The Linear Method — Practices for Building
There is a lost art of building true quality software. To bring back the right focus, here are the foundational ideas Linear is built on.
Table of Contents
Principles
These are the core beliefs that shape how to build quality software:
Build for the Creators
Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.
Purpose-Built
Productivity software needs to be designed for purpose. It's the only way the product can truly do the heavy lifting. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.
Create Momentum — Don't Sprint
Find a cadence and routine of working. In cycles, you can decide priorities and assign responsibilities. The goal is to maintain a healthy momentum with your teams, not to rush towards the end.
Meaningful Direction
Even if your daily schedule is filled with smaller tasks, it's important to understand and remind everyone of the purpose and long-term goals of your work. Milestones, projects, and initiatives are all essential to consider when you plan your weekly schedules.
Aim for Clarity
Don't invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects. Issues should be called issues.
Say No to Busy Work
Your tools should not make you the designer and maintainer of them. A tool should work for you, not the other way around. Remove or automate "work around work", so you can focus on what really matters.
Simple First, Then Powerful
Teams have different needs depending on their size. A tool should be simple to get started with and grow more powerful as you scale.
Decide and Move On
There isn't always a best answer. Sometimes the most important thing is to make a decision, and move on.
Practices
These are the repeatable methods that put the principles into action:
1. Set Strategic Product Initiatives
Define ambitious, high-level goals. Use initiatives to articulate vision and map out how the product will grow. Allow for unexpected work by leaving wiggle room in timelines.
2. Connect Daily Work to Larger Goals with Projects
Every project should align with the strategic initiatives. During planning cycles, review projects, track target dates, prioritize accordingly. Make sure each project maps back to a broader goal so that work feels purposeful and aligned.
3. Work in N-Week Cycles
Use regular, finite cycles (commonly 2 weeks) to commit to specific work. Enough time to build something meaningful, short enough to stay focused. Don't overload them. Let unfinished work roll over into the next cycle.
4. Keep a Manageable Backlog
Not every piece of feedback or idea needs to be saved forever. Keep the focus on what matters. A lean backlog helps planning and ensures work gets done. If something's important, it'll surface again.
5. Mix Feature and Quality Work
Include bug fixes, improvements, and tooling as part of cycles, not afterthoughts. Including technical debt or maintenance makes future work smoother.
6. Specify Project and Issue Owners
Each project should have a single person accountable for the brief, scope, and delivery. Same for issues. Even when multiple people contribute, there's one owner.
7. Write Project Specs
Keep specs short but clear — include why, what, and how. Helps with scoping, clarity, and reducing waste. Short, clear specs help families of team members understand and avoid building the wrong thing.
8. Understand Your Users
User feedback is a rich source of guidance. Collect it, study it, detect patterns. Attach feedback to issues so the voice of customers lives close to the work. Bring user feedback into the process.
9. Scope Issues to Be As Small As Possible
Smaller, discrete tasks are easier to finish, review, and show progress. Large issues should be sliced. Small tasks = faster feedback, visible progress.
10. Measure Progress with Actual Work
Use visible output (code diffs, completed designs) to show progress. Avoid huge pull requests or massive changes in one go. Show real changes, small diffs.
11. Run Cross-Functional Teams
Designers, engineers, and other roles collaborate closely. Design informs implementation; engineering influences design. Shared ownership across disciplines leads to better solutions.
12. Write a Changelog
For internal clarity and transparency to users. Keep both internal and external stakeholders updated. Celebrate what shipped, reflect on what's new. Helps everyone see progress.
Direction
How to set the broader context: vision, goals, and priority.
Set the Product Direction
Setting direction is one of the most important things you'll do when building a product and company. A clear direction:
- Aligns everyone to work toward the same goals
- Helps individuals make daily decisions
- Helps teams prioritize projects
- Makes all members feel motivated toward a shared purpose
Without direction, it's harder to work together, know what to focus on, and make meaningful progress.
Initiatives are a critical tool for shaping direction. The process of creating initiatives and mapping out a product journey forces you to articulate a vision and decide how to build toward it. Anyone in your company can look at the product initiatives to quickly understand what the most important streams of work are, why they matter, and how they are progressing.
Set Useful Goals
Goals anchor what matters. Even early on, it's okay to start with what feels ambitious and measurable. These guide priorities. You'll often backcast from the goal to find the first meaningful steps.
Prioritize Enablers and Blockers
Make sure foundational work (frameworks, infrastructure, removing obstacles) gets enough attention. Blockers slow everything down. Address things that unblock progress or enable future better work — these often get deprioritized but are crucial.
Scope Projects Down
Limit project size and scope so you can deliver quickly, reduce risk, and iterate more. Break large work into smaller projects. Avoid bloated features; think small and iterative.
Building
Practices for the execution phase — where you build, adapt, and iterate.
Generate Momentum
You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.
There will also be weeks when you won't necessarily know what is the most important thing to do or you're not sure what decision to make in the product. Don't become paralyzed in those moments — find a way to act instead. Trust your intuition and do something that seems to make sense. Talk to more users. You'll gain more clarity as more feedback rolls in.
If you've designed your operations to move fast and learn, then you can correct or revert decisions.
Write Issues, Not User Stories
At Linear, they don't write user stories — they consider them an anti-pattern. Instead, they write short and simple issues in plain language.
Why User Stories Are Obsolete
- They were made in a different era; customers can often express what they want directly
- Many common features don't need elaborate storytelling
- User stories can hide what needs to be done; obscure tasks
- They can force an engineer into following spec rather than thinking holistically
A better way to write issues:
- Describe concrete tasks or problems — Specify what needs doing in actionable terms
- Write clearly and directly — Simple titles, minimal but adequate descriptions. Add context only when needed
- Write your own issues — Whoever understands the task should write it. Builds clarity & ownership
- Keep product-level discussions at the product level — UX/design thinking belongs in conversations before breaking work into tasks
Manage Design Projects
Treat design work with the same rigor and clarity as engineering. Use briefs, specs, and feedback. Verified problem → explore freely → get feedback before locking things down. Cross-team alignment before code means less rework.
Build With Users
Involve users, gather real feedback, iterate. Don't assume what's best — test and refine. Balance your vision with feedback. Ask "What problem are you trying to solve?" more than "What feature do you want?"
Collect feedback continuously; use it to guide improvements. Always be learning.
Launch and Keep Launching
Ship often. Deliver value incrementally. Launch small, iterate. Shipping regularly — even small features — helps refine direction and gives real momentum.
Build in Public
Transparency helps. Whether internal or external, sharing what you are doing helps alignment and trust. Publish changes regularly through changelogs. Encourages shipping, transparency, and accountability.
Summary
The Linear Method balances structure with flexibility. It emphasizes:
| Focus Area | Key Idea |
|---|---|
| Clarity | Purpose and goals are clear to everyone |
| Small chunks | Incremental, measurable work |
| Alignment | Teams move toward ambitious initiatives together |
| No busywork | Tools serve work, not the other way around |
| Iteration | Continuous feedback and improvement |
You don't have to follow it rigidly — but using these practices as guiding principles helps teams build better software, faster, and with more purpose.